The development trend in information technology is increasingly toward parallel systems. There are two basic ways of realizing such systems. On the one hand, the hardware can be realized in parallel (vector such as a processor or, transputer). With developments of this type, the parallel design at the hardware level is taken into account by suitable compilers at the software level, as described in the publication by G. Raebel, Ein vektorisierender Pascal-Compiler from Informatik in der Praxis:Aspekte ihrer industriellen Nutzanwendung, Springer-Verlag, 1986, pages 220-221. This situation is usually referred to as low-level parallelism.
A further realization approach is high-level parallelism. In this case, the mapping of parallel objects of the real world onto parallel units in the software is already begun during the software design phase. The object-oriented programming technique is increasingly being used for this. Objects capable of running in parallel can be processed in the operating system used irrespective of the underlying hardware architecture. The term concurrent class has become established to describe the classes from which such objects capable of running in parallel are derived.
The testing of such concurrent class objects brings up new problems. These problems result firstly from the higher level of abstraction on which the programmer works during object-oriented programming. Secondly, these problems arise from the parallelism, particularly in the case of the time-dependent process communication between objects that takes place in time-critical applications.
Test processes shown in, for example, the publication by Peter Liggesmeyer, Modultest und Modulverifikation: state of the art, BI-Wissenschaftsverlag, 1990, pages 49-51, hitherto known from the literature are based on the fact that software modules are instrumented for example. This means that the software to be tested is provided with an additional section of special software code which permits statements, or conclusion about the operability of the software to be made during program execution. Particularly in connection with program modules which are capable of running in parallel on one processor and which communicate with one another in a time-dependent manner, this process has serious disadvantages:
The software to be tested is changed by the instrumentation. This change affects the runtime behavior.
The temporal execution of the objects in relation to one another is affected by these interventions in the software to be tested.
The level to which buffers are filled for process messages is affected.
Taken together, the effect of these disadvantages is that with the test processes to date, it is impossible to make any absolute statements about the runtime behavior and execution of the software under observation shown in, for example, the publication by Peter Liggesmeyer, Modultest und Modulverifikation: state of the art, BI-Wissenschaftsverlag, 1990, pages 49-51.
An object of the invention is to provide a process for performing at least one test on at least one of the objects of an object-oriented program capable of running in parallel on a computer.
This object is achieved by a process for performing at least one test on at least one of the objects of an object-oriented program capable of running in parallel on a computer, having the following features:
a) a method call takes place via routines for message exchange provided in an operating system of the computer, the routines being executed via an interrupt handler in the operating system of the computer,
b) it is checked with each interrupt handling caused by step a) whether the computer is to operate in a test mode,
c) interactively input tests or automatic tests are processed during the test mode,
d) a system clock of the computer is paused during the processing of tests,
e) during the processing of the tests, allocation information of the object code to the source code of the object-oriented program and vice versa is accessed.
Further developments of the invention provide that in the process all interrupt handling apart from that for the input and output is blocked during the processing of the tests. As a further development, at least one method call is changed, suppressed and/or additionally incorporated. The process provides that the runtime of an object is determined by the system time that elapses between two successive method calls.
Additional advantages are provided when the allocation information relates to method names. Also, the allocation information preferably relates to parameter values. Specifically, the allocation information relates to parameter data types. In a preferred embodiment, the allocation information relates to parameter designations.
A particular advantage of the application of the process according to the invention is that specific test scenarios can be readily created by starting or terminating individual objects.
In order not to influence the execution of the test, it is favorable, with the interrupt handling provided in the process according to the invention, to permit only interrupts for input and output in the operating system during the test phase.
When applying the process according to the invention, it is favorable that method calls can be changed, suppressed, logged or added simply, with a comparison of a current method call with a given nominal method call being possible.
It is furthermore favorable when using the process according to the invention that buffer contents can be read non-destructively, and that it is possible to obtain information about pending method calls in connection with objects by analyzing the queues of the operating system.
The pausing of the system clock envisioned according to the invention proves to be favorable if one wishes to establish the runtime of an object, since this is obtained from the difference in time between two successive method calls.
The provision of allocation information during the test is particularly favorable in the process according to the invention. This also makes it possible for the programmer to test from the level of abstraction that is customary for him during programming. The allocation information creates a link from the abstraction level of the object-oriented programming to the object code level. Information such as object name, parameter type, parameter name, parameter data type, which is lost during compilation is restored as a result of the allocation information.
This makes it possible for the programmer to design his test to be efficient, since he can use the same designations for parameter names and object names as during programming in order to create corresponding test scenarios.